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DETAILED ACTION 

1 . Claims 1-22 are pending in this application. 

Claim Rejections - 35 USC § 102 

2. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
States. 

3. Claim 3 is rejected under 35 U.S.C. 102(b) as being anticipated by U.S. Pat. 
No. 6,223,134 B1 to Rust et al. 

4. As to claim 3, Rust teaches a method for commonly controlling device drivers, 
comprising the steps of: arranging a device independent access hierarchy between an 
application hierarchy and a device driver hierarchy (figure 5 (Class Drivers 304) Col. 13 
Ln. 19 - 67); defining functions available in a corresponding device driver among 
functions of a function block in a function table (Col. 6 Ln. 34 - 51 , IVI engine 306 Col. 
16 Ln. 28-49, "...array of function names..." Col. 23 Ln. 29-42); when a device is 
initialized, allowing said device independent access hierarchy to generate a device 
handler identifier based on a standardized data format for said device and transmit the 
generated device handler identifier to the application hierarchy of a higher order 
("...returns a handle..." Col. 20 Ln. 35-46, "...handle... returned..." Col. 23 Ln. 12-21, 
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"...returns a handle..." Col. 24 Ln. 22-29); and allowing the higher-order application 
hierarchy to call a predetermined device using the device handler identifier ("...this 
handle..." Col. 23 Ln. 12-28, "...use this handle..." Col. 24 Ln. 22-29), and allowing 
said device independent access hierarchy to identify a function of the corresponding 
device driver from the function table using the device handler identifier ("...pointer..." 
Col. 16 Ln. 28-49, "...this handle..." Col. 23 Ln. 12-28, Col. 24 Ln. 1 - 11) and call 
the function of the corresponding device driver ("...this handle..." Col. 23 Ln. 12 - 28, 
Col. 24 Ln. 22-29). 

Claim Rejections - 35 USC § 103 

5. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

6. Claim 1 is rejected under 35 U.S.C. 103(a) as being unpatentable over U.S. 
Pat. No. 6,505,258 B1 to Sakarda et al. in view of U.S. Pat. No. 6,697,884 B1 
Katsch. 

7. As to claim 1 , Sakarda teaches a method for commonly controlling device 
drivers, comprising the steps of: arranging a device independent access hierarchy 
figures 3/4 File System Driver 405/Bridge Device Driver 415/Type Specific Driver 420) 
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between an application hierarchy ("...application program..." Col. 9 Ln. 46 - 56, 
"Application programs..." Col. 10 Ln. 65 - 67) and a device driver hierarchy (figure 4 
Device Specific Driver 425) and applying a standardized rule of said device independent 
access hierarchy to said application hierarchy and said device driver hierarchy and 
allowing said application hierarchy to access the device driver hierarchy through the 
standardized rule of said device independent access hierarchy ("...file system..." Col. 9 
Ln. 48 - 56, Type Specific Driver (TSD) 420 Col. 1 1 Ln. 27 - 29, Bridge Device Driver 
41 5); when device is initialized, allowing said device independent access hierarchy to 
generate a device handier identifier having a standardized common data format for said 
device ("...identifies the peripheral device, writes the identity..." Col. 4 Ln. 62 - 66, 
"...parameter information..." Col. 12 Ln. 43-67); and allowing said device application 
hierarchy and said device driver hierarchy to access said the device driver hierarchy 
and said application hierarchy through the standardized rule of said device independent 
access hierarchy, respectively ("...permit communication..." Col. 4 Ln. 62 - 67, Col. 5 
Ln. 23-27, "...send the request..." Col. 9 Ln. 46-56, "...communicate..." Col. 10 Ln. 
65 - 67). 

Sakarda is silent with reference to transmitting the generated device handler 
identifier to the application hierarchy of a higher order. 

Katsch teaches transmitting the generated device handler identifier to the 
application hierarchy of a higher order ("...the host obtains configuration information..." 
Col. 2 Ln. 16-28, "...transmit data in response..." Col. 5 Ln. 6-8, Ln. 337-42, 
"...reply..." Col. 6 Ln. 20 - 30, Ln. 45 - 67). 
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It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify system of Sakarda with the teaching of Katsch because 
the teaching of Katsch would improve the system of Sakarda by providing a discovery 
procedure that starts by a host device sending a first command to all peripheral devices 
connected to the serial communication bus to determine if the configuration of any of 
the peripheral devices has changed (Katsch Col. 2 Ln. 7 - 10). 

8. Claim 12 is rejected under 35 U.S.C. 103(a) as being unpatentable over U.S. 
Pub. No. 2002/0170039 A1 to Kovacevic in view of U.S. Pub. No. 2003/0037180 A1 
to Madineni et al. 

9. As to claim 12, Kovacevic teaches a method, comprising: requesting loss of 
signal state information state information having a standardized common format by an 
application to a device independent access hierarchy ("...user control or status read- 
back..." page 1 paragraph 0015, "...generate... commands..." page 2 paragraphs 0017- 
0019); converting the request from said application into a first device local format and 
requesting a first device driver to provide state information to said independent access 
hierarchy ("...convert the commands to generic commands..." page 2 paragraph 
0017/0019, "...translate commands..." (Steps 710-740) page 5 paragraphs 0050-0052). 

Kovacevic does not explicitly teach responding to the request for state 
information having the first device local format and responding to said application by 
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said device independent access hierarchy for loss of signal state information based on 
the standardized common format. 

Madineni teaches responding to the request for state information having the first 
device local format ("...only send s single, low-level message..." page 3 paragraph 
0027) and responding to said application by said device independent access hierarchy 
for loss of signal state information based on the standardized common format ("...may 
also notify any interested application programs..." page 3 paragraph 0027, page 4 
paragraph 0036/0037, page 5 paragraph 0039). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the system of Kovacevic with the teaching of Madineni 
because the teaching of Madineni would improve the system of Kovacevic by providing 
technique for transparently responding to control/status request from a requesting 
application (Madineni page 4 paragraph 0036). 

10. Claims 1,2 and 12-21 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over U.S. Pat. No. 6,223,134 B1 to Rust et al. in view of U.S. Pat. No. 
6,993,772 B2 to Pike et al. 

11. As to claim 1 , Rust teaches a method for commonly controlling device drivers, 
comprising the steps of: arranging a device independent access hierarchy between an 
application hierarchy and a device driver hierarchy (figure 5 (Class Drivers 304) Col. 13 
Ln. 1 9 - 67) and applying a standardized rule of said device independent access 
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hierarchy to said application hierarchy and said device driver hierarchy (IVI Engine 306 
Col. 16 Ln. 28 - 49); when a device is initialized, allowing said device independent 
access hierarchy to generate a device handler identifier having a standard common 
data format for said device and transmitting the generated device handler identifier 
having the standardized common data format to the application hierarchy of a higher 
order ("...returns a handle..." Col. 20 Ln. 35-46, "...handle... returned..." Col. 23 Ln. 
12-21, "...returns a handle..." Col. 24 Ln. 22-29) and allowing said application 
hierarchy to access the device driver hierarchy through the standardized rule of said 
device independent access hierarchy (Col. 6 Ln. 34-51, Class Drivers 304 Col. 16 Ln. 
28-67). 

Rust is silent with reference to allowing said device driver hierarchy to access 
said application hierarchy through the standardized rule of said device independent 
access hierarchy. 

Pike teaches allowing said device driver hierarchy to access said application 
hierarchy through the standardized rule of said device independent access hierarchy 
(Instrument Engine 102 "...sent and read to and from..." Col. 8 Ln. 3-14). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify system of Rust with the teaching of Pike because the 
teaching of Pike would improve the system of Rust by allowing communication between 
a user application and device driver such that a response could be returned to the user 
application. 



Application/Control Number: Page 8 

10/607,167 

Art Unit: 2194 

1 2. As to claim 2, Pike teaches the method as set forth in claim 1 , with said step of 
allowing said application hierarchy and said device driver hierarchy to access, further 
comprising the steps of: allowing said application hierarchy to transmit control 
commands having the on a standardized common data format for a corresponding 
device driver to said device independent access hierarchy, and allowing said device 
independent access hierarchy to convert the control commands into other control 
commands having a local format and transmit the converted control commands to said 
device driver; and allowing said device driver to give a response to the converted 
control commands having the local format to said device independent access hierarchy, 
and allowing the device independent access hierarchy to convert the response from 
said device driver into a response having the standardized common data format and 
transmit the response based on the standardized common data format to said 
application hierarchy ("...translate(s)..." Col. 7 Ln. 25-55, Instrument Engine 102 
("...formats... sent and read to and from..." Col. 8 Ln. 3-14). 

13. As to claim 12, Rust teaches a method, comprising: requesting loss of signal 
("...check instrument status...") state information having a standardized common format 
by an application to a device independent access hierarchy (figure 8A (Step 472) Col. 
24 Ln. 32 - 37); the device independent access hierarchy allows the request from said 
application to provided in a first device local format ("...only required to have knowledge 
of the class driver 304..." Col. 15 Ln. 24 - 45) and requesting a first device driver to 
provide the loss of signal state information to said device independent access hierarchy 
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(figure 8A (step 478) Col. 24 Ln. 43 - 45); responding to the request for loss of signal 
state information having the first device local format (figure 8B (Step 487) Col. 23 - 27); 
responding to said application by said device independent access hierarchy for loss of 
signal state information having the standardized common format (Check Status 
Callback Col. 36 Ln. 46 - 49, figure 25B (Step 928) Col. 40 Ln. 15 - 20). 

Rust does not explicitly teach converting the request from said application into a 
first device local format. 

Pike teaches converting the request from said application into a first device local 
format ("...translate(s)..." Col. 7 Ln. 25-55, Instrument Engine 102 ("...formats... sent 
and read to and from..." Col. 8 Ln. 3 - 14). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the system of Rust with the teaching of Pike because the 
teaching of Pike would improve the system of Rust by providing a powerful, concise 
mechanism that allows users to easily and quickly communicate details of different 
hardware interfaces having a distinct application program interface or driver modules 
(Pike Col. 3 Ln. 31 - 35). 

14. As to claim 13, Rust teaches the method of claim 12, with said step of converting 
the request from said application further comprising of converting the request into a 
second device local format and requesting a second device driver to provide the loss of 
signal state information to said device independent access hierarchy having the second 
device local format when a first device is converted to a second device and said first 
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device driver is changed to said second device driver (Abstract ("...interchangeable 
instrument drivers), "...interchangeability..." Col. 6 Ln. 18-28, "...substitute other 
instruments..." Col. 7 Ln. 42 - 50, "...replace..." Col. 8 Ln. 22-28, Col. 15 Ln. 3 - 6). 

15. As to claim 14, Rust teaches the method of claim 13, further comprising of 
converting control commands having the standardized common format to control 
commands provided to the device drivers accommodating a change of said application 
to a second application without changing the control commands provided to the device 
drivers (Abstract "...interchangeable instrument drivers..."). 

16. As to claim 15, Rust teaches the method of claim 14, further comprised of 
providing a mutual interface between said application and said first and second device 
drivers by the device independent access hierarchy (Col. 13 Ln. 19 - 44); reading 
material from a device driver control block and accessing the first and second device 
drivers using predetermined functions (figure 5, Col. 16 Ln. 28 - 56, Col. 20 Ln. 1 - 46). 

17. As to claim 16, Rust teaches the method of claim 15, further comprising of said 
device independent access hierarchy using device handler identifiers having the 
standardized data format, said device handler identifiers corresponding to respective 
devices ("...handle..." Col. 20 Ln. 38-46, "...handle..." Col. 23 Ln. 12-21). 
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18. As to claim 17, Rust teaches the method of claim 16, further comprising: 
providing the device handler identifiers to said application from said device independent 
access hierarchy during an initialization of the corresponding device; and storing, by 
said application, the device handler identifiers and calling a corresponding device using 
a corresponding device handler identifier ("...handle..." Col. 20 Ln. 38 - 46, 
"...handle..." Col. 23 Ln. 12-21). 

19. As to claim 18, Rust teaches the method of claim 17, further comprising of said 
device independent access hierarchy determining according to said device handler 
identifier whether a certain device handler should be called and calling the certain 
device handler according to the determination ("...handle..." Col. 20 Ln. 38-46, 
"...handle..." Col. 23 Ln. 12-21). 

20. As to claim 19, Rust the method of claim 18, with the device independent access 
hierarchy using certain pointers and function pointers in performing the standardized 
common format in the device independent access hierarchy (Col. 16 Ln. 22 - 49, Col. 
20 Ln. 52 - 67, Col. 21 Ln. 17 - 30). 

21 . As to claim 20, Rust teaches the method of claim 1 9, further comprised of when 
said application is calling a function of a function block to be used, said device 
independent access hierarchy identifies the existence of a corresponding function from 
a function table and uses a device handler identifier to inform the initialization of the 
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device driver accommodating said application to access a device driver using said 
device handler identifier ("...handle..." Col. 20 Ln. 38-46, "...handle..." Col. 23 Ln. 12 



22. As to claim 21 , Rust teaches the method of claim 20, further comprised of not 
varying the device handler identifier value for the device when said first device driver is 
changed to said second device driver ("...handle..." Col. 20 Ln. 38-46, "...handle..." 
Col. 23 Ln. 12-21). 

Allowable Subject Matter 

Claims 6-1 1 are allowed. 

Claims 4-5 and 22 are objected to as being dependent upon a rejected base 
claim, but would be allowable if rewritten in independent form including all of the 
limitations of the base claim and any intervening claims. 

Response to Arguments 

Applicant's arguments with respect to claims 1-3 and 12-21 have been 
considered but are moot in view of the new ground(s) of rejection. 

Conclusion 

The prior art made of record and not relied upon is considered pertinent to 



-21). 



applicant's disclosure. 




- Application/Control Number: 



Page 13 



10/607,167 
Art Unit: 2194 

U.S. Pub. No. 2002/0059474 A1 to Camara et al.: directed to system and method 
for using script-bed device drivers to operate hardware devices. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Charles E. Anya whose telephone number is (571) 272- 
3757. The examiner can normally be reached on M-F (8:30-5:00). 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, William Thomson can be reached on (571) 272-3718. The fax phone 
number for the organization where this application or proceeding is assigned is 571- 
273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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